One or more data secrets should be “owned” by an authentication secret. In other words, a user must authenticate with a given authentication secret to gain access to a certain data secret. No other authentication secret should be able to be used to gain access to the associated data secret. In order to link data secrets with a corresponding authentication secret (e.g., defining which data secret is owned by (or associated with) which authentication secret), a look-up table is typically employed in which each data identifier (DataId) for a given data secret is matched up with the authentication identifier (AuthId) of the corresponding authentication secret that owns the data secret. The look-up table association, however, is explicitly stored in the server's database.
From a security perspective, explicitly storing the association between data secrets and corresponding authentication secrets means that an attacker who steals the database will obtain the association between data secrets and corresponding authentication secrets. If, for instance, the attacker knows that a certain authentication secret belongs to a user of interest, then the attacker may wish to concentrate their efforts on obtaining (and recovering) the data secrets associated with the authentication secret for the user of interest (the data secrets may be individually protected at the server).
In addition, explicitly storing the association between data secrets and corresponding authentication secrets (e.g., having a link between a value in one table and a value in another table) causes scalability issues.
A need therefore exists for methods and apparatus for linking secrets by identifiers without explicit storage of the linking values in the server (i.e., without storing the association between authentication and data secrets in the database of the server). A further need exists for methods and apparatus for mathematically determining the identifiers.